home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / tcp / 940176.txt < prev    next >
Text File  |  1994-11-13  |  18KB  |  724 lines

  1. Date: Thu, 18 Aug 94 04:30:01 PDT
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V94 #176
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Thu, 18 Aug 94       Volume 94 : Issue  176
  11.  
  12. Today's Topics:
  13.                 DAMA Implementaion and Interpretation
  14.                       Okie Thoughts #2 (9 msgs)
  15.                            Okie thoughts 2
  16.                            PRUG WWW server
  17.                          X1J gurus? (2 msgs)
  18.  
  19. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  20. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  21. Problems you can't solve otherwise to brian@ucsd.edu.
  22.  
  23. Archives of past issues of the TCP-Group Digest are available
  24. (by FTP only) from UCSD.Edu in directory "mailarchives".
  25.  
  26. We trust that readers are intelligent enough to realize that all text
  27. herein consists of personal comments and does not represent the official
  28. policies or positions of any party.  Your mileage may vary.  So there.
  29. ----------------------------------------------------------------------
  30.  
  31. Date: Thu, 18 Aug 94 08:51:01 EST
  32. From: BARRY TITMARSH <BTITMARS%ESOC.BITNET@vm.gmd.de>
  33. Subject: DAMA Implementaion and Interpretation
  34. To: TCP-GROUP <TCP-GROUP@ucsd.edu>, wnos-group <WNOS-L@EDUGRAF.UFSC.BR>
  35.  
  36. ARRL : 8th Computer Networking Conference - October 7, 1989 - page 203-209
  37.  
  38.             DAMA - A NEW METHOD OF HANDLING PACKETS ?
  39.             ==========================================
  40.  
  41. by Detlef J. SCHMIDT, DK4EG   Steinbrecherstr. 22    D-38106 BRAUNSCHWEIG
  42.  
  43.                         NORD><LINK e.V.
  44.                         c/o Peter Glzow, DB2OS
  45.                         Allensteiner Str. 5
  46.                         D-30880 LAATZEN
  47.                         Germany
  48.  
  49.               Translation : Mark Bitterlich, WA3JPY
  50.               Reprint     : Pierre Cornelis, ON7PC
  51.  
  52.  
  53. ª...ß
  54.  
  55. Connect Establish :
  56. -------------------
  57.  
  58. When a node attempts to connect to a user, the node adds the users ID to
  59. it's polling list and begins to send SABMs to that station. If after a
  60. certain amount of tries no UA is received, the user is assumed to be
  61. inoperable and is removed from the polling list.
  62.  
  63. When a new user starts a connect sequence to the node, he begins by sending
  64. SABMs to the master in a simple CSMA manner duplicating the existing method
  65. used today. Collisions are possible during this phase, so it might be
  66. necessary to repeat the SABMs several times until the node replies with a
  67. UA. Once the node recognizes the users connection attempt, the users ID is
  68. added to the polling list in a fashion very similar to the one used by
  69. TheNet nodes (TheNet userlist) and the node (master) is now in control of
  70. the uplink users station.
  71.  
  72. After the user sends SABMs and the node replies
  73. with a UA,
  74.  
  75. the user replies with an RR0 to signal to the node that it had a
  76.                          £££££££££££££
  77. >>> this can also be interpreted as sending an I frame NR=0 NS=0
  78. >>> if the upper layer has data to send in the case of tcpip
  79. >>> Comments please ??
  80.  
  81. successful reception of UA.
  82.  
  83.  
  84. ª...ß
  85.  
  86. uhf sent (Sun Aug 14 09:41:33 1994):
  87. AX25: DC0HK to DB0RT-10 via DB0DAR SABM(P)
  88.  
  89. uhf recv (Sun Aug 14 09:41:41 1994):
  90. AX25: DB0RT-10 to DC0HK via DB0DAR* UA(F) ªDAMAß
  91.  
  92. uhf sent (Sun Aug 14 09:41:41 1994):
  93. AX25: DC0HK to DB0RT-10 via DB0DAR I NR=0 NS=0 pid=IP
  94. IP: len 84 44.130.24.71->44.130.60.100 ihl 20 ttl 63 prot ICMP
  95. ICMP: type Echo Request id 63232 seq 0
  96. .............. !"#$%&'()*+,-./01234567
  97.  
  98.  
  99. >>> as can be seen in the above trace.. I believe that at the time dama was
  100. >>> invented it did not! consider upper layers of ax25 like tcpip and L3/L4
  101. >>> netrom which acts the exact same way.
  102.  
  103.  
  104.    Or have I read this the wrong way ?? I have a local dama digi sysop
  105. who thinks different. Please some constructive comments, I have seen no
  106. responce yet, from you guys.
  107.  
  108. Thanks Barry gm8sau/dc0hk
  109.  
  110. ------------------------------
  111.  
  112. Date: Wed, 17 Aug 94 11:51:36      
  113. From: kz1f@RELAY.HDN.LEGENT.COM
  114. Subject: Okie Thoughts #2
  115. To: "Brian A. Lantz" <brian@lantz.cftnet.com>, tcp-group@ucsd.edu
  116.  
  117. > >  This message is in MIME format.  The first part should be readable text,
  118. > >  while the remaining parts are likely unreadable without MIME-aware tools.
  119.  
  120. I, for one, was pleasantly surprised to see a MIME msg arrive here. This 
  121. means that altleast some of us are moving past the 1970's, 821 is all but 
  122. dead. Going forward is a good thing!
  123.  
  124. WAlt
  125.  
  126. ------------------------------
  127.  
  128. Date: Wed, 17 Aug 94 12:53:30      
  129. From: jks@giskard.utmem.edu
  130. Subject: Okie Thoughts #2
  131. To: kz1f@RELAY.HDN.LEGENT.COM, "Brian A. Lantz" <brian@lantz.cftnet.com>,
  132.  
  133. Walt said:
  134. > I, for one, was pleasantly surprised to see a MIME msg arrive here.
  135.  
  136. Me too... wake up guys the future is already here with implementation of 
  137. RFC 1521...
  138.  
  139.  
  140. Jack Spitznagel - KD4IZ
  141.  
  142. ------------------------------
  143.  
  144. Date: Wed, 17 Aug 1994 14:58:16 -0400
  145. From: "Brandon S. Allbery" <bsa@kf8nh.wariat.org>
  146. Subject: Okie Thoughts #2 
  147. To: jks@giskard.utmem.edu
  148.  
  149. In your message of Wed, 17 Aug 1994 12:53:30, you write:
  150. +---------------
  151. | Me too... wake up guys the future is already here with implementation of 
  152. | RFC 1521...
  153. +------------->8
  154.  
  155. The obvious question, however, is:  who's writing the MIME-capable external 
  156. mailer(s) for DOS (and especially, one for use with NOS)?  Let's face it; the 
  157. audience of tcp-group isn't all on Unix boxes.
  158.  
  159. ++Brandon
  160. -- 
  161. Brandon S. Allbery KF8NH     [44.70.4.88]          bsa@kf8nh.wariat.org
  162. Linux development:  iBCS2, JNOS, MH
  163.  
  164. ------------------------------
  165.  
  166. Date: Wed, 17 Aug 94 16:35:14      
  167. From: kz1f@RELAY.HDN.LEGENT.COM
  168. Subject: Okie Thoughts #2
  169. To: "Brandon S. Allbery" <bsa@kf8nh.wariat.org>, tcp-group@ucsd.edu
  170.  
  171. > The obvious question, however, is:  who's writing the MIME-capable 
  172. > external mailer(s) for DOS (and especially, one for use with NOS)?  Let's
  173. > face it; the audience of tcp-group isn't all on Unix boxes.
  174.  
  175. Brandon, neither are we...Its OS/2 (as well as Unix). Not to start a jehad 
  176. (awgh but why not), I think the DOS folks are in for a rude awakening, I 
  177. dont know of anyone doing dosnos anymore, its OS/2 or Linux. And its tough 
  178. to fit anymore code into DOS anyways. The idea behind MIME is sending voice,
  179. bmp's, exe's and data too. So, even if someone were willing to write the RFC
  180. to DOS, what are you going to play the audio with and what are you going to 
  181. display the bmp's with...etc etc.
  182.  Walt
  183.  
  184. ------------------------------
  185.  
  186. Date: Wed, 17 Aug 1994 17:30:32 -0400
  187. From: "Brandon S. Allbery" <bsa@kf8nh.wariat.org>
  188. Subject: Okie Thoughts #2 
  189. To: kz1f@RELAY.HDN.LEGENT.COM
  190.  
  191. In your message of Wed, 17 Aug 1994 16:35:14, you write:
  192. +---------------
  193. | Brandon, neither are we...Its OS/2 (as well as Unix). Not to start a jehad 
  194. | (awgh but why not), I think the DOS folks are in for a rude awakening, I 
  195. | dont know of anyone doing dosnos anymore, its OS/2 or Linux. And its tough 
  196. +------------->8
  197.  
  198. I know quite a few who are still on DOS, and I'm on record as disrecommending 
  199. JNOS for Linux for the average leaf node.  NOS for DOS still has some life in 
  200. it, especially when run under DESQview or MS-Windows (or OS/2, etc.) and 
  201. provided with decent external mailers.  I suspect that not even a stable 
  202. MS-Windows 4.x will kill off DOS any time soon; look how long Apple ][, CP/M, 
  203. etc. hung on against the IBM PC.
  204.  
  205. ++Brandon
  206. -- 
  207. Brandon S. Allbery KF8NH     [44.70.4.88]          bsa@kf8nh.wariat.org
  208. Linux development:  iBCS2, JNOS, MH
  209.  
  210. ------------------------------
  211.  
  212. Date: Wed, 17 Aug 1994 14:56:37 -0700
  213. From: brian@nothing.ucsd.edu (Brian Kantor)
  214. Subject: Okie Thoughts #2
  215. To: tcp-group@ucsd.edu
  216.  
  217. Until you have something that does MIME in a more natural way, feel free
  218. to use the following little utility.
  219.     - Brian
  220.  
  221.  
  222.  
  223. /*
  224.  * Brian Kantor's stupid little MIME encode/decode utility
  225.  *
  226.  * I'm not proud of this code.
  227.  *
  228.  * this runs fine on a Sun.  Elsewhere, you're on your own.
  229.  *
  230.  * copyright (c) 1994 give it away but don't sell it
  231.  */
  232. #include <stdio.h>
  233.  
  234. int eflag = 0;
  235. int hflag = 0;
  236. int qflag = 0;
  237.  
  238. int lsz = 0;
  239.  
  240. main(argc,argv)
  241. int argc;
  242. char *argv[];
  243.     {
  244.     int c;
  245.  
  246.     if (argc < 2)
  247.         {
  248.         fprintf(stderr,"Usage: mime {-e|-d} [-h] {-b|-q}\n");
  249.         exit(1);
  250.         }
  251.  
  252.     while ( (c = getopt(argc, argv, "edhbq")) != -1)
  253.         {
  254.         switch(c)
  255.             {
  256.     case 'd':
  257.             eflag = 0;
  258.             break;
  259.     case 'e':
  260.             eflag = 1;
  261.             break;
  262.     case 'h':
  263.             hflag = 1;
  264.             break;
  265.     case 'b':
  266.             qflag = 0;
  267.             break;
  268.     case 'q':
  269.             qflag = 1;
  270.             break;
  271.             }
  272.         continue;
  273.         }
  274.  
  275.     fprintf(stderr, "%s input, %scode %s\n",
  276.         (hflag?"hex":"binary"),
  277.         (eflag?"en":"de"), (qflag?"qp":"b64"));
  278.  
  279.     if (eflag)        /* encode */
  280.         {
  281.         if (qflag)
  282.             qpencode();
  283.         else
  284.             b64encode();
  285.         }
  286.     else
  287.         {        /* decode */
  288.         if (qflag)
  289.             qpdecode();
  290.         else
  291.             b64decode();
  292.         }
  293.     }
  294.  
  295. int
  296. inchar()
  297.     {
  298.     char buf[4];
  299.  
  300.     if (hflag)
  301.         {
  302.         buf[0] = getchar();
  303.         if (feof(stdin))
  304.             return(EOF);
  305.         buf[1] = getchar();
  306.         if (feof(stdin))
  307.             return(EOF);
  308.         buf[3] = 0;
  309.         return(strtol(buf, 0, 16));
  310.         }
  311.     else
  312.         return(getchar());
  313.     }
  314.     
  315.     
  316. static char HEX[] = "0123456789ABCDEF";
  317.  
  318. int
  319. qpencode()
  320.     {
  321.     int c, i;
  322.  
  323.     while (1)
  324.         {
  325.         c = inchar();
  326.         if (c == EOF)
  327.             return;
  328.  
  329.         /* EOL */
  330.         if (c == 10)
  331.             {
  332.             putchar(c);
  333.             lsz = 0;
  334.             continue;
  335.             }
  336.  
  337.         /* printable char not '=' */
  338.         if (c >= 32 && c <= 126 && c != 61)
  339.             {
  340.             lchk(1,1);
  341.             putchar(c);
  342.             continue;
  343.             }
  344.  
  345.         /* everything else gets encoded */
  346.         lchk(3,1);
  347.         putchar('=');
  348.         putchar(HEX[(c & 0x0f0) >> 4]);
  349.         putchar(HEX[(c & 0x0f)]);
  350.         }
  351.     }
  352.  
  353. lchk(n,q)
  354. int n,q;
  355.     {
  356.     lsz += n;
  357.     if (lsz > 72)
  358.         {
  359.         if (q)    /* qp encoded */
  360.             puts("=");
  361.         else
  362.             putchar('\n');
  363.         lsz = 0;
  364.         }
  365.     }
  366.  
  367.  
  368. static char B64[] =
  369.    "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";
  370.  
  371. int
  372. b64encode()
  373.     {
  374.     int c, i;
  375.     int bbuf[8];
  376.  
  377.     i = 0;
  378.     bzero(bbuf, sizeof bbuf);
  379.  
  380.     while (1)
  381.         {
  382.         c = getc(stdin);
  383.         if (feof(stdin))
  384.             break;
  385.         
  386.         bbuf[i++] = c & 0xff;
  387.  
  388.         /* when we have 3 chars, squirt out 4 encoded bytes */
  389.         if (i >= 3)
  390.             {
  391.             lchk(4,0);
  392.  
  393.             putchunk(3, bbuf);
  394.  
  395.             i = 0;
  396.             bzero(bbuf, sizeof bbuf);
  397.             }
  398.         }
  399.  
  400.     putchunk(i, bbuf);
  401.     }
  402.  
  403. putchunk(nc,bf)
  404. int nc;
  405. int bf[];
  406.     {
  407.     int np;
  408.  
  409. #define OB(x)  (putchar((B64[(x) & 63])))
  410.  
  411.     if (nc <= 0)
  412.         return;
  413.     if (nc > 3)
  414.         return;
  415.  
  416.     if (nc > 0)
  417.         {
  418.         /* top six bits of first byte */
  419.         OB((bf[0] & 0xfc) >> 2);
  420.         /* bot 2 bits of first byte, top 4 bits of 2nd byte */
  421.         OB(((bf[0] & 3) << 4) | ((bf[1] &0xf0) >> 4));
  422.         }
  423.  
  424.     if (nc > 1)
  425.         /* bot 4 bits of 2nd, top 2 bits of 3rd */
  426.         OB(((bf[1] & 0x0f) << 2) | ((bf[2] & 0xc0) >> 6));
  427.  
  428.     if (nc > 2)
  429.         /* bot 6 bits of 3rd */
  430.         OB(bf[2]);
  431.  
  432.     np = 3 - nc;
  433.     while (np-- > 0)
  434.         putchar('=');
  435.     }
  436.  
  437. /*
  438.  * decode Quoted-Printable mime message line
  439.  * squirts out as hex file image to ccmail file
  440.  */
  441. int
  442. qpdecode()
  443.     {
  444.     int escaped;
  445.     int c;
  446.     char buf[4];
  447.  
  448.     escaped = 0;
  449.     while (1)
  450.         {
  451.         c = inchar();
  452.         if (c == EOF)
  453.             return;
  454.  
  455.         if (c == '\n')
  456.             {
  457.             if (!escaped)    /* EOL == hard NL unless escaped */
  458.                 putchar(0x0a);
  459.             escaped = 0;
  460.             continue;
  461.             }
  462.  
  463.         /* is it an unencoded character */
  464.         if (c == '=')    /* QP escape character */
  465.             {
  466.             escaped = 1;
  467.             continue;
  468.             }
  469.         
  470.         /* not escaped, not escape char, output it */
  471.         if (!escaped)
  472.             {
  473.             putchar(c & 0xff);
  474.             continue;
  475.             }
  476.  
  477.         /* expect two hex chars after escape */
  478.         buf[0] = c;
  479.         buf[1] = inchar();
  480.         buf[3] = 0;
  481.         c = strtol(buf, 0, 16);
  482.         putchar(c);
  483.         escaped = 0;
  484.         continue;
  485.         }
  486.     }
  487.  
  488.  
  489. /*
  490.  * decodes base-64-encoded text
  491.  * by turning each 4 base-64 characters into 3 8-bit bytes
  492.  * and then outputting them
  493.  */
  494. b64decode()
  495.     {
  496.     char *b;
  497.     int i;
  498.     unsigned c, c1, c2, c3;
  499.     int cc;
  500.  
  501.     i = 1;
  502.  
  503.     while((cc = inchar()) != EOF)
  504.         {
  505.         b = (char *)index(B64, cc);
  506.         if (b == NULL)
  507.             continue;
  508.  
  509.         c = (unsigned)(b - B64);
  510.  
  511.         switch(i++)
  512.             {
  513.     case 1:
  514.             c1 = ( (c & 0x3f) << 2);    /* 1st 6 bits of c1 */
  515.             c2 = c3 = 0;
  516.             continue;
  517.     case 2:
  518.             c1 |= ( (c & 0x30) >> 4);    /* 2nd 2 bits of c1 */
  519.             c2 = ( (c & 0x0f) << 4);    /* 1st 4 bits of c2 */
  520.             continue;
  521.     case 3:
  522.             c2 |= ( (c & 0x3c) >> 2);    /* 2nd 4 bits of c2 */
  523.             c3 = ( (c & 0x03) << 6);    /* 1st 2 bits of c3 */
  524.             continue;
  525.     case 4:
  526.             c3 |= (c & 0x3f);        /* 2nd 6 bits of c3 */
  527.             i = 1;
  528.             break;
  529.             }
  530.  
  531.         putchar(c1);
  532.         putchar(c2);
  533.         putchar(c3);
  534.         }
  535.     if (i == 4)
  536.         fprintf(stderr, "early eof in b64decode\n");
  537.     if (i == 2 || i == 3)
  538.         putchar(c1);
  539.     if (i == 3)
  540.         putchar(c2);
  541.     }
  542.  
  543. ------------------------------
  544.  
  545. Date: Wed, 17 Aug 1994 15:31:49 -0700 (PDT)
  546. From: Lyndon Nerenberg <lyndon@canada.unbc.edu>
  547. Subject: Okie Thoughts #2 
  548. To: "Brandon S. Allbery" <bsa@kf8nh.wariat.org>
  549.  
  550. In the PC world you can run Eudora under Windoze, or Pmail under raw DOS 
  551. as well as Windoze, if you require MIME support.
  552.  
  553. Both are freeware. (Yes, there is also a commercial version of Eudora, 
  554. but the free one works fine, too.)
  555.  
  556. --lyndon  VE7TCP/VE6BBM
  557.  
  558. ------------------------------
  559.  
  560. Date: Thu, 18 Aug 1994 08:42:13 EET
  561. From: "Markus Lamminmaki OH6LSA" <MARKUS@TECHNIS.VTYH.FI>
  562. Subject: Okie Thoughts #2 
  563. To: tcp-group@UCSD.EDU
  564.  
  565. >+---------------
  566. >| Me too... wake up guys the future is already here with implementation of 
  567. >| RFC 1521...
  568. >+------------->8
  569. >
  570. >The obvious question, however, is:  who's writing the MIME-capable external 
  571. >mailer(s) for DOS (and especially, one for use with NOS)?  Let's face it; the 
  572. >audience of tcp-group isn't all on Unix boxes.
  573. >
  574. >++Brandon
  575.  
  576. Well, you could try PMAIL, you can get it working with NOS. Wery good 
  577. peace of software indeed, you can find it atleast in risc.ua.edu or 
  578. tyr.let.rug.nl.
  579.  
  580.  
  581. ---
  582. Vasa Polytechnic              Email: markus@technis.vtyh.fi
  583. PB 6, SF-65201, FINLAND              postmaster@vtyh.fi
  584. Fax: +358-61-3230 610         Please, someone, make X.400 go away!
  585. Work:+358-61-3230 661         Home:  +358-61-3171 466
  586.  
  587.         Death, drums and guitars, they finaly got it right! (B&Bh)
  588.  
  589. ------------------------------
  590.  
  591. Date: Thu, 18 Aug 94 9:29:37 DST
  592. From: Martin W Freiss <freiss.pad@sni.de>
  593. Subject: Okie Thoughts #2
  594. To: kz1f@RELAY.HDN.LEGENT.COM
  595.  
  596. > > The obvious question, however, is:  who's writing the MIME-capable 
  597. > > external mailer(s) for DOS (and especially, one for use with NOS)?  Let's
  598. > > face it; the audience of tcp-group isn't all on Unix boxes.
  599. > Brandon, neither are we...Its OS/2 (as well as Unix). Not to start a jehad 
  600. > (awgh but why not), I think the DOS folks are in for a rude awakening, I 
  601. > dont know of anyone doing dosnos anymore, its OS/2 or Linux. And its tough 
  602. > to fit anymore code into DOS anyways. The idea behind MIME is sending voice,
  603. > bmp's, exe's and data too. So, even if someone were willing to write the RFC
  604. > to DOS, what are you going to play the audio with and what are you going to 
  605. > display the bmp's with...etc etc.
  606.  
  607. With external programs spawned by the mailer. I do it this way with PCElm 3.21,
  608. which does it crudely, but it works, using freeware and shareware programs
  609. to play voicemail through a soundblaster card and view JPG pictures.
  610. This approach is suggested in one of the RFCs (I forgot the number)  about
  611. MIME, and is both easy to code and easy to configure.
  612.  
  613. So, MIME works under DOS. Of course, an integrated multimedia work
  614. environment with mail under DOS (something like Andrew) will be nigh impossible.
  615.  
  616. Trying to send digitized voice over a congested 1200 Bd packet link is another
  617. matter entirely :-)
  618.  
  619. -Martin
  620.  
  621. --
  622.  Martin Freiss               | R&D computer center | freiss.pad@sni.de 
  623.  Siemens Nixdorf Infosystems | Dept. MR OI 4       | NIC MF194
  624.  Paderborn, Germany          | Phone +49 5251 8 15642
  625. "The average pointer, statistically, points somewhere in X." -Hugh Redelmeier
  626.  
  627. ------------------------------
  628.  
  629. Date: Thu, 18 Aug 94 09:03:00 BST
  630. From: Martin Lines <mlines@sni.co.uk>
  631. Subject: Okie thoughts 2
  632. To: tcp-group@UCSD.EDU
  633.  
  634. Haven't we gone around the same loop again?
  635.  
  636. Shouldn't NOS be acting as a front-end comms box. Mine
  637. is and as a consequence who cares that it runs on DOS?.
  638.  
  639. Surely its up to the mailer how it handles MIME etc not the mail
  640. infrastructure and there are a few suitable MIME mailers
  641. around for use on any access system (Windows etc)
  642.  
  643. Flames to /dev/null
  644.  
  645. Martin Lines
  646.  
  647. mlines@sni.co.uk
  648.  
  649. ------------------------------
  650.  
  651. Date: Thu, 18 Aug 1994 20:10:44 +0900
  652. From: Isao SEKI <seki@nanno.tama.prug.or.jp>
  653. Subject: PRUG WWW server
  654. To: tcp-group@UCSD.EDU
  655.  
  656. Hi ALL,
  657.  
  658. We have exported WWW server at "Hamfair '94" on japanese day time
  659. (UT -0900) from today to Aug.21. At server had many japanese euc 
  660. text and many PRUG members pictures.
  661.     http://pdemo01.hamfair.prug.or.jp/
  662.     (163.213.30.1)
  663. And we have exported every time
  664.     http://www.prug.or.jp/
  665.  
  666. PRUG - Packet Radio Users' Group
  667. Hamfair - Bigest ham's festival at Japan.
  668.  
  669. Isao
  670. ---
  671. Isao SEKI / JM1WBB (HAM Radio)
  672. EMail: seki@tama.prug.or.jp (NeXT Mail OK) / iseki@cisco.com
  673.  
  674. ------------------------------
  675.  
  676. Date: Wed, 17 Aug 94 08:17:20 CDT
  677. From: mfoster@amoco.com (Michael H. Foster)
  678. Subject: X1J gurus?
  679. To: nos-bbs@hydra.carleton.ca, tcp-group@UCSD.EDU
  680.  
  681. Has anyone optimized their x1j parms?
  682. With several band openings over the past few weeks, the x1j's locally
  683. lose their buffer space and hose up until a reset is given.  We are 
  684. trying different parm settings hoping the node will release it's buffer
  685. space faster, but we have no serious documentation to guide these settings.
  686. Can anyone provide any insight or specifics? 
  687.  
  688. Thanks in advance,
  689. Mike, wa5txx
  690. mfoster@amoco.com
  691.  
  692. ------------------------------
  693.  
  694. Date: Thu, 18 Aug 1994 02:38:49 -0700 (PDT)
  695. From: Bob Merritt <ka4byp@netcom.com>
  696. Subject: X1J gurus?
  697. To: "Michael H. Foster" <mfoster@amoco.com>
  698.  
  699. On Wed, 17 Aug 1994, Michael H. Foster wrote:
  700.  
  701. > Has anyone optimized their x1j parms? > With several band openings over
  702. the past few weeks, the x1j's locally > lose their buffer space and hose
  703. up until a reset is given.  We are > trying different parm settings hoping
  704. the node will release it's buffer > space faster, but we have no serious
  705. documentation to guide these settings. > Can anyone provide any insight or
  706. specifics?  > 
  707.  
  708. Mike...  we found that decreasing the max # of nodes to 30,
  709. and increasing the min qual to abt 120 helps the most in that area.  Other
  710. things to do is to disable help, and reduce the mheard #.  Also, we
  711. installed a 10MHz speed up kit from Paccomm that keeps the buffers up near
  712. 600-700 and cpu looping at 900-1200.  Hope that helps... 
  713.  
  714. 73/bob
  715.  
  716. *******
  717. Bob Merritt  KA4BYP  ----->  ka4byp@netcom.com  <-----
  718.  
  719. ------------------------------
  720.  
  721. End of TCP-Group Digest V94 #176
  722. ******************************
  723.